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The  Letter  of  Agrteinent  (LOA)  is  a jointly  prepared  and  authenti- 
cated document  initiated  by  an  Army  combat  developer  (user)  and  material 
developer  (developer).  The  LOA  is  used  as  the  supporting  document  for 
the  advanced  phase  of  researcii  and  development  (6.3B).  The  utilization 
of  the  LOA  in  this  manner  is  a unique  and  innovative  method  of  defining 
system  needs/requirements  which  is  peculiar  to  the  Army.  The  LOA  pro- 
vides the  Army  with  a control  document  which  authorizes  entry  into  the 
Conceptual/Validation  (Advanced  Development)  phase  without  committing 
to  specifics  early  in  the  acquisition  process.  It  allows  the  Army  con- 
siderable latitude  prior  to  final  commitment  to  a particular  system 
which  is  accomplished  later  ttirough  the  initiation  of  e Required  Opera- 
tio))al  Capability  (ROC)  document.  The  ROC  is  prepared  after  DSARC  II 
decision  to  enable  entry  into  Full  Scale  Development. 

This  paper  provides  a short,  historical  summary  on  some  of  the 
criticism  leveled  against  the  Army's  acquisition  procedures  which  re- 
sulted ill  the  adoption  of  the  use  of  the  LOA.  It  covers  the  specific 
requirements  of  the  LOA,  provides  a procedural  and  processing  model  for 
LOA  developrsent,  and  finally  format  instructions.  These  sections  should 
provide  valuable  information  for  an  inexperienced  action  officer  tasked 
with  tl;e  preparation  of  an  LOA. 

To  evaluate  the  current  prccedurcs , the  report  covers  some  comments 
received  from  personnel  who  have  worked  the  system.  A synopsis  of 


thoir  comments  indicates  enthusiastic  acceptance  and  response  for 
the  procedures.  Although  some  conflict  areas  were  identified,  they 
were  not  considered  to  be  serious  or  unresolvable. 


The  report  concludes  that  the  LOA  seems  to  be  a step  in  the  right 
direction  to  improve  Army  acquisition  procedures.  It  should  siletice 
some  of  the  Army's  critics  of  the  needs/requirements  generation  pro- 
cess. Although  this  report  indicates  favorable  response  to  the  new 
Army  acquisition  procedures,  it  is  recommended  that  a follow-on  study 
be  conducted  to  determine  what  the  specific  benefits  have  been  in  terms 
of  savings  in  time,  money  and  performance  improvement. 
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SECTION  I 


INTRODUCTION 

The  acquisition  of  quality  equipment  for  the  U.  S.  Army  soldier 
has  in  recent  years  become  a highly  visible,  extremely  controversial, 
and  much  maligned  process.  It  is  in  the  area  of  systems  acquisition 
where  the  "big"  budget  dollars  within  the  Department  of  Defense  (DOD) 
utilized  for  research  and  development  of  major  systems  finds  many  of 
its  critics.  This  is  an  area  also  where  the  Department  of  Defense  has 
been  concentrating  efforts  in  order  to  improve  its  track  record;  fully 
recognizing  that  the  process  of  developing  new  systems  is  a horrendously 
difficult,  demanding  and  painstaking  task  for  those  charged  with  its  re- 
sponsibility. 

Purpose . 

The  systems  acquisition  guidelines  used  in  the  development  process 
contain  several  document  requirements  which  are  used  to  start  the  ac- 
quisition process.  It  is  the  purpose  of  this  paper  to  look  at  one  of 
these  documents  — the  Letter  of  Agreement  (LOA).  The  Army  has  pub- 
lished several  regulations  which  reference  the  use  of  the  LOA,  and  has 
produced  guidelines  for  formating  and  processing  it,  which  will  be 
discussed  later.  Since  the  approval  of  the  LOA  is  one  of  the  first 
documents  required  to  initiate  the  acquisition  process,  it  is  the  intent 
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of  this  paper  to  discuss  in  some  detail  its  evolution  and  the  process, 
procedures  and  problems  associated  with  the  development  and  the  generation 
of  an  approved  LOA. 

Goals. 

Through  the  discussion  it  will  be  possible  to  determine  the  in- 
puts required,  and  the  procedures  for  processing  the  LOA  through  the 
user  and  developer  commands. 

Significant  Definitions. 

The  LOA  is  a jointly  prepared  and  authenticated  document  in  which 
the  combat  developer  and  the  materiel  developer  outline  the  basic  agree- 
ments for  further  investigations  of  a potential  materiel  system.  The 
materiel  and  combat  developer  both  agree  that  a materiel  concept  has 
sufficient  interest,  importance,  operational  and  technical  potential  to 
warrant  the  commitment  of  advanced  development  resources  to  obtain  more 
definitive  information.  The  LOA  will  describe  the  further  investigation 
and  testing  needed  to  develop  and  validate  the  system  concept,  and  will 
establish  the  investigations  needed  to  define  the  operational,  techni- 
cal, and  logistic  elements  of  the  materiel  concept.  The  LOA  is  the 
document  of  record  to  support  effort  in  the  system  advanced  development 
category  of  the  ROTE  program.  (8,  C-2)^ 

^This  notation  will  be  used  throughout  the  report  for  sources  of 
quotations  and  major  references  quoted  directly.  The  first  number  is 
the  source  listed  in  the  bibliography.  The  second  number  is  the  page 
in  the  reference. 
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The  Required  Operational  Capability  (ROC)  is  a HQ,  DA  document 
vihidi  states  concisely  tlie  niiniirium  essential  operational,  technical, 
logistical,  and  cost  information  necessary  to  initiate  full  scale  de- 
velopment or  procurement  of  a materiel  system.  (5,  A-3) 

The  combat  developer  is  the  command  or  agency  responsible  for  the 
formulation  of  doctrine,  concepts,  materiel  requirements  and  objectives, 
and  organizations  for  the  employment  of  Army  forces  in  a theater  of 
operations  and  in  control  of  civil  disturbances.  (6,  A-1 ) The  principle 
combat  developer,  trainer  and  user  representative  for  the  Army  is  the 
U.  S.  Army  Training  and  Doctrine  Command  (TRADOC). 

The  materiel  developer  is  the  comm, and  or  agency  responsible  for 
research,  development  and  production  validatio.n  of  a system  (to  include 
the  system  for  its  logistic  support)  v/hich  responds  to  HQ,  DA  objectives 
and  requirements.  Materiel  developers  vrill  be  designated  from  the  follow- 
ing, with  specific  responsibilities  assigned  as  appropriate:  Chief  of 

Engineers;  The  Surgeon  General;  Commanding  General,  Development  and 
Readiness  Command  (previously  AKC);  Commanding  General,  U.  S.  Army  Com- 
puter Systems  Command;  Cominanding  General,  Army  Security  Agency;  Deputy 
Chief  of  Staff,  Research,  Development  & Acquisition;  Commanding  General, 

U.  S.  Army  Co'"municatinps  Command;  and.  Commanding  Officer,  U.  S,  Army 
Institute  for  Dehavio’^ial  & Social  Sciences.  (6,  A-3)  For  the  pur- 
pose of  this  paper,  l!Q,  DARCO’l  is  considered  the  principal  materiel 
developer. 


Scope. 


A discussion  of  some  of  the  historical  basis,  the  evolution  of 
the  LOA  in  the  present  system  acquisition  process,  and  tiie  actual 
procedures  presently  utilized  will  bo  addressed. 

Linii  tations . 

The  report  addresses  itself  strictly  to  the  requirements  documents 
of  the  U.  S.  Army.  Although  several  references  are  made  to  total  ser- 
vice (DOD)  problems  to  illustrate  various  points,  the  scope  of  the  re- 
quirenent  documents  utilized  is  limited  to  the  present  use  of  the  LOA 
as  the  Army's  requireinent/need  document. 

The  report  is  also  limited  in  scale  to  a very  small  sample  size 
from  which  actual  experience  using  the  system  and  procedures  has  been 
taken.  To  lend  greater  creditability  to  the  findings,  it  \,'ould  bo  neces- 
sary to  sap'ple  several  individual  action  officers  from  each  school, 
headquarters,  commiodity  cor/mands,  etc.,  through  which  LOA's  are  generated 
and  processed. 

Since  each  LOA  generated  involves  very  few  of  tlie  same  personnel 
iti  each  case,  it  is  highly  probable  that  individual  cases  could  be 
found  >.;hich  nay  refute  some  of  the  opinions  and  statements  made  in 
this  report. 


4 


Generally  speakincj,  however,  it  is  believed  that  personnel  inter- 
viewed stated  views  which  would  be  representative  of  those  which  could 
be  found  in  r.ost  organizations  processing  LOA's. 

Organization . 

The  report  is  organized  under  the  topic  area  sections  of  an  intro- 
duction, historical  sunrsary,  LOA  requirenents , LOA  preparation,  evaluation 
of  current  LOA  procedures  and  a suinrary. 

The  sections  have,  in  soine  cases,  several  subsections  dealing  with 
topics  which  tend  to  expand  or  clarify  various  points  to  be  made. 


SECT  I o:.'  II 


HISTORICAL  SUr.MARY 

The  priiiary  documents  v.'hich  were  utilized  in  the  past  to  define 
user  requirements  which  the  developer  worked  to  try  and  meet  were  the 
Materiel  Heed  Document  (MH)  and  the  Required  Operation  Capability  (ROC). 
Many  major  Army  projects  ire  yet  today  working  against  Materiel  Needs 
(HN's),  i.e.,  AAH,  HELLFIRL.  The  MN  was  generated  by  the  user  and  for- 
malized  by  the  Combat  Development  Command  which,  under  an  Army  reorgani- 
zation, has  been  deactivated  with  TRADOC  now  responsible  for  CDC's  pre- 
vious activities.  There  was  minimum  developer  participation  and  staffing 
prior  to  issuance  of  an  MN  as  the  user's  need  requirement. 

Since  it  was  not  a user/devel oper  coordinated  document,  the  MN 
often  contained  specifications  and  requirements  which  were  beyond  the 
state-cf-tho-an;  of  technology  or  beyond  the  time  range  and  cost  scope 
the  Army  could  a '"ford  or  was  willing  to  pay.  As  a result,  to  field  the 
system  it  was  necessary  to  usually  v/aive  many  of  the  requirements  which 
could  not  be  met.  Prior  to  waiver,  however,  there  was  always  a very 
large  expenditure  of  manpower,  noney  and  tip’O  involved  in  first  trying 
to  meet  the  requirement  and  then  documenting  the  case  in  order  to  get 
v/aivers  approved.  The  system  using  the  MN  was  made  to  work  but  was 
burdened  with  problems  related  to  requirements  gerieration  and  need 
definition . 
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The  MM  was  the  forerunner  of  what  is  now  knov/n  as  the  POC  (required 
oporationai  capability)  which  definiti;^os  the  user's  requirements  prior 
to  the  initiation  of  full  scale  development.  The  ROC  became  the  require- 
ment document  and  ivas  utilized  during  the  period  June  1 972-November  1974, 
until  the  revised  AR  1000-1  was  published.  In  the  5 floveinber  1974, 

AR  1000-1,  the  ROC  was  modified  to  become  the  document  utilized  to  take 
a system  into  full  scale  development.  (More  will  be  said  about  the  ROC 
later  in  the  paper.) 

The  LOA  is  now  being  utilized  as  the  initiating  document  which  be- 
gins the  process  of  definitizing  the  ROC,  and  allows  the  developer  and 
user  to  set  down  the  broad  requirements  of  the  system  in  an  organized 
and  ccordinated  position  to  proceed  into  the  conceptual  end  validation 
phases  of  the  acquisition  cycle. 

In  the  early  70' s,  several  commissions  were  established  by  Congress 
to  look  specifically  at  the  DOD  weapons  acquisition  system  then  in  being. 
As  a result  of  one  such  committee's  efforts,  .several  findings  and  recom- 
mendations were  reported  v/hich  were  directly  related  to  all  throe  ser- 
vices in  their  generation  of  needs  and  requirements  for  systems.  The 
following  discussion  will  relate  to  those  findings. 

Report  of  the  Commission  on  Government  Procurement.  (1 ,0) 

Of  particular  interest  in  thi.s  report  wo'g  the  discussions  and 
recommendations  l.aving  to  do  with  estal)!  ishi ng  needs  and  coals,  and 
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thu  problems  caased  by  tlie  vested  interests  end  motivations  of  the 
principles  involved  in  the  acquisition  process. 

Tiie  report  was  critical  of  the  needs  and  requirement  goals  es- 
tablished for  major  v.'oapon  systems  and  traces  tfie  procedures  used  in 
the  acquisition  process  through  the  1960‘s  to  the  present  starting  with 
ttie  Programming,  Planning  and  Budgeting  System  incorporated  during  the 
Mciiamara  era.  During  this  period,  and  up  to  the  present,  the  DoD  ac- 
quisition policy  has  been  to  delegate  the  first  decisions  on  needs  and 
the  responsibility  for  defining  systems  to  each  military  service.  The 
first  stateiaent  of  a need  originates  within  any  of  the  organizations 
in  a rjfilitary  service  or  in  conjunction  with  industry  through  unsolicited 
proposals.  Tlie  Army  used  as  its  principle  document  t!ie  Materiel  Meed  (Mli) 
and,  with  the  new  Departinent  of  Defense  directive  concerning  material  ac- 
quisition, v/ent  to  the  Required  Operatioiial  Capability  Documents  (ROC's) 
in  the  early  1970's.  The  ROC  could  originate  anywhere  in  the  Army  - 
at  one  of  the  schools  or  centers  in  one  of  the  operational  commands, 
in  the  Army  Materiel  Command  (AMC),  Combat  Development  Command  (CDC), 

Army  Staff,  Secretariat,  or  the  idea  might  originate  with  industi-y.  (1,  39) 

Criticisn:  of  this  system  of  need  generation  involved; 

p 

1.  The  stdter:ent  of  need  did  not  clearly  separate 
the  problci'i  from  the  solution.  Early  acquisition  plans 
concentrated  on  a needed  new  system  and  a prefe''rt;d 


Ttii«  nol-M. -'nn  at.'l  fo>-;:'at  will  he  nsed  throunh.i;  t tiio  report  for 
service-  of  long  gijot..jtions  omitlirm  m-ir..  onotation  marks. 
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system  approach  witfi  inadequate  attention  to  why 
any  new  capability  was  needed  or  what  that  capa- 
bility was  worth.  One  of  the  reasons  new  systems 
have  become  more  cor:';plex  and  costly  has  been  the 
tendency  to  say,  "\;hat  it  is  we  need"  from  the 
outset  in  accemmodatinq  a host  of  stipulations 
on  system  characteristics  and  performance.  (1,  40) 

2.  Needs  were  defined  by  each  service  with- 
out letter  or  formal  aqoncywide  coordination. 

Needs  were  subject  to  individual  priorities  which 
led  to  duplication  in  system  capabilities.  (1,  40) 

3.  The  initial  statements  of  needs  to  start 
acquisition  programis  did  not  separate  operational 
needs  from  system  solutions,  and  did  not  present 
program  goals  independently  of  a particular  system. 

The  titles  of  the  statement  of  needs  (the  ROC's 

of  the  Army)  implied  that  they  were  statements  of 
the  opei'ational  problem  to  be  solved,  which  tliey 
were  in  part,  but  they  also  move  directly  with  a 
preferred  system  product  in  considerable  detail.  (1,  41) 


In  other  words,  we  were  defining  a need,  then  tying  it  to  a proposed 
system  to  meet  the  need  by  specifying  all  the  things  it  would  be  required 
to  have  in  it  or  be  able  to  do.  We  were,  in  effect,  solving  the  problem 
by  defining  in  detail  the  preferred  system.  Stipulations  in  the  need 
statement  caused  the  focus  to  be  on  a product  rather  than  its  purpose. 

Needs  that  are  set  in  terms  of  the  system  to  be  built  tend  to  deny, 
delay  and  overextend  the  application  of  new  technical  approaches.  However 
programs  fon'ulated  and  pursued  with  attention  focused  on  particular  sys- 
tems can  lock-in  on  technical  approaches  which  may  lie  too  advanced  and 
unattainable. 
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As  a result  of  these  criticisms,  the  committee  recommended  the 
following: 

Start  new  system  acquisition  programs  with  agency 
head  statements  of  needs  and  goals  that  have 
been  reconciled  with  overall  agency  capa- 
bilities and  resources. 

a.  State  program  needs  and  goals  independently 
of  any  system  product.  Use  long  term  projections 
of  mission  capabilities  and  deficiencies  prepared 
and  cooi'dinated  by  agency  components  to  set  program 
goals  that  specify: 

(1)  Total  mission  costs  within  which  new 
systems  should  be  bouglit  and  used. 

(2)  The  level  of  mission  capability  to  be 
achieved  above  that  of  projected  inventories  and 
existing  systems. 

(3)  The  time  period  in  which  the  new  capa- 
bility is  to  be  acirieved. 

b.  Assign  responsibility  for  responding  to 
statement  of  needs  and  goals  to  agency  components 
in  such  a way  that  either: 

(1)  A single  agency  component  is  responsi- 
ble for  developing  system  alternatives  when  the 
mission  need  is  clearly  the  responsibility  of  one 
component;  or 

(2)  Competition  between  agency  components 
is  formally  recognized  with  each  offering  alter- 
native system  solutions  when  tlie  mission  responsi- 
bi I ities  overlap.  (1 , 11) 


AHARC  Committee  Report. 

It  was  during  the  time  that  the  subconmi ttee  report  discussed  above 
was  being  compiled  tliat  the  Arr'V  issued  AR  1000-1  wirich  was  dated  ?0 
•June  1972.  Shortly  thereafter  it  also  published  a "Letter  of  Instructions" 
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implementing  AR  1000-1,  dated  23  August  1972,  ifeithcr  of  these  docu- 
ments yet  mentioned  the  use  of  the  LOA.  During  this  period  of  time, 
the  requirements  document  for  the  Army  v/as  the  ROC  v/hich  replaced  the 
MN. 

The  Army  operated  its  acquisition  system  under  these  guides  for 
approximately  orio  year.  It  was,  however,  still  very  much  concerned 
with  its  acquisition  system  even  after  implementing  all  the  changes  out- 
lined in  the  1971  DODD  5000.1,  and  its  new  AR  1000-1  and  implemeriLing 
LOT.  In  December  1973,  DA  formed  the  Army  Materiel  Acquisition  Review 
Committee  (AMARC)  to  further  review  the  Army's  total  materiel  acquisition 
process . 

As  one  might  expect,  the  AMARC  Committee  reported  as  had  the  Con- 
gressional subcommittee  tliat  one  of  tiie  Army's  problems  continued  to  be 
its  needs  or  requi reiients  generation  process  which  locked  in  too  early 
in  the  cycle  the  system  description  and  requirements. 

The  following  question  was  presented  by  the  AMARC. 

How  should  the  Army  embark  in  the  development  of 
a material  system? 

The  AMARC  discussion  included  the  following-. 

(1)  The  Arr-iy  initiates  programs  leading  to  develop- 
ment of  a syston'  througii  approval  of  a Required  Op- 
erational Capability  (ROC).  !'uc  to  tiie  frequent 
changes  (Apr  71  and  Aug  72)  in  tfie  docum-’iitation 
supporting  the  Army's  acquisition  process,  there 
are  a variety  of  documents  currently  serving  as 
approved  roquireiacnts  documents  in  addition  to  the 
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ROC,  e.g..  Qua!  itative  Mc.teriel  Requirement  (Q.’IR) 
and  Materiel  ileed  (Engineering  Development)  (MD[EDj). 

Ho  matter  what  name  o''  format  has  been  used,  the 
document  serves  as  the  "user"  statement  of  iiis 
need  for  a system. 

(2)  The  theory  is  tiiat  the  user  can  specify 
what  his  needs  arc  and  the  developing  agency 
can  respond  to  this  document  by  developing  the 

required  equipment  in  a straigiitforward  and  ex-  , 

peditious  fashion  in  accordance  with  approved  pro-  I 

cedures...we  believe  tliat  this  concept  is  v;orkable  i 

for  acquisition  of  already  developed  equipment 
or  improvement  actions  to  standard  equipment 
where  the  technology  is  well  in  hand,  the  user 
thoroughly  understands  what  the  improved  equip- 
ment will  do,  and  thie  developer  has  adequate  j 

data  on  cost  and  schedule.  1!ie  concept  is  un-  ] 

workable  when  a new  class  or  type  of  equipment  1 

is  to  be  developed  and  required...  (3,  1-7)  1 


AMARC  also  looked  at  the  question  of  ho'w  should  requirements  be 

established?  In  answering  this  question,  it  recommended 

...that  t(ie  concept  of  a user  docuirent  be 
accepted  to  guide  system  advanced  develop- 
ment (G.3C)...and  that  the  ROC  be  prepared 
after  successful  completion  of  advanced  de- 
velopment. (3,  I-B) 


As  a result  of  the  AMARC  recommendations,  the  Army  issued  a re- 
vised AR  1000-1,  dated  5 Hovember  1974,  effective  1 January  1975,  which 
incorporates  the  concept  of  e joint  user/developer  document,  the  LOA 
as  the  guide  to  system  advanced  development  and  the  utilization  of  tne 
ROC  i-or  entry  into  full  scale  development. 
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SCCTION  III 


LOA  REQIJIRLMENTS 


Rer.cjrcli  and  devel oppient  efforts  for  systems  ac- 
quisition should  be  initiated  ivitli  modest  programs, 
avoid  unsupported  promises  as  to  system  expectations, 
and  recognize  fully  the  tedniical  risks  and  uncertain- 
ties. A foi’iiial  feonij^nent,  i.'ith  its  implicit  con'mi  t- 
nient  to  an  essential' prclluction  decision,  will  not 
be  established  until  a tnorougii  advanced  development 
program  has  been  conducted  to  include  testing  of  com- 
ponents and/or  prototypes,  to  adequately  demonstrate 
both  tfie  technical  and  operational  feasibility.  The 
dcvel opriiont , improvement  and/o>'  prpeuremem  of  ma- 
teriel systems  must  result  from  an  active  dialogue 
betv/een  the  combat  developer  and  the  materiel  de- 
veloper. When  a requirement  cannot  be  satisfied  by 
existing  equipment,  the  materiel  and  combat  developer 
shall  jointly  determine  if  an  improved  or  new  system 
could  he  satisfactory  ... 

Tlie  system  cor)cept  will  be  developed  and  validated 
jointly  by  the  n:atoriel  developer  and  combat  developer 
prior  to  formal  commitment  by  the  Army  to  the  need 
for  the  system.  ...  The  objective  of  the  Conceptual 
and  Validation  Phases  is  to  provide  a basis  for 
timely  )o\;-risk  full-scale  development  of  new 
systcni'iS  or  improver.ent  of  existing  systems  and 
to  insure  that  the  information  necessary  foe  the 
Arniy  to  (ieteriHiiie  the  best  course  of  action  is 
developed  and  reviewed.  ...  (7,  1 & 2) 


The  excerpt  above  is  the  lead-in  discussion  to  the  section  in  AR 
1000-1  v/hich  provides  th^  general  guideline  requirements  for  the  genera- 
tion of  an  LOA.  Roth  AR  1000-1  and  AR  71-9  provide  information  which  is 
extremely  useful  for  preparation  of  an  lOA.  UARCOM  and  TRADOC  Headquarters 
have  recently  published  a flateriel  Acquisition  Handbook,  d<ated  1 Rovembe'- 
137b,  which  provides  explanations  for  tlie  joint  development  of  each 


materiel  acquisition  document  and  describes  the  combat  and  materiel  de- 
veloper interface. 


The  Materiel  Acquisition  Handbook  provides  the  fol levying  guidance: 

The  jointly  prepared  and  authenticated  LOA  is  required  under  most  i 

conditions,  befc'e  new  starts  involving  G.3B  funds  can  be  obligated.  Tne 
primary  purpose  of  the  LOA  is  to  insure  TRADOC  and  UARCOM  are  in  agreement 
on  the  nature  and  characteristics  of  a proposed  system.  The  LOA  also  in- 
sures that  the  two  commands  are  aware  of  the  investigations  needed  to 
develop  and  validate  the  concepts  for  the  system,  the  definition  of  the 
associated  operational,  technical  and  logistics  support  concepts,  and 

i 

finally  the  interactions  to  promote  harmonious  development  of  the  system  | 

between  the  developer  and  the  user.  j 

The  LOA  is  a document  of  record  which  supports  the  effort  in  the 
System  Advanced  Development  (Concept  & Validation)  6.3B  category  of  re- 
search and  development. 

Preparation  of  the  LOA  is  usually  accomplished  at  a proponent  TRADOC 
school  such  as  the  Field  Artillery  School,  at  Fort  Sill,  Oklahoma  and 
at  the  DARCOM  commodity  coinmand/laboratory  level  such  as  the  Missile  Com- 
mand, at  Redstone  Arsenal,  Alabama.  If  the  LOA  research  and  development 
costs  for  Advanced  Development  are  less  than  $10  million,  approval  can  be 
made  at  the  DARCOm/TRADOC  Command  level.  If  research  and  development 
costs  exceed  $10  million,  the  LOA  is  forwarded  by  tlic  user  to  Headquarters, 

i 
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Department  of  the  Army,  Deputy  Chief  of  Staff  for  Operations  (HQOA  [DCSOPS]) 
for  approval.  Systems  which  were  initially  projected  to  be  less  than  $10 
million  and  subsequently  exceed  that  threshold  require  the  user  to  up- 
date the  LOA  and  forward  it  to  flQDA  (DCSOPS)  for  approval.  All  other  LOA 
will  be  sent  to  HQDA  (DCSOPS)  for  information  and  appropriate  distribution 
to  the  DA  Staff.  The  LOA  is  the  basis  for  research  and  development  end 
force  development  effort  prior  to  full-scale  development. 
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SECIIOIJ  IV 

LOA  PREPAUATION  (9,  3-2-3-7) 

The  user  (TRADOC)  upon  receipt  of  a requirenent,  assinns  one  of 
its  scliools  as  the  proponent  agency.  The  school  prepares  a draft  of  the 
LOA  including  as  much  detail  as  is  possible  based  upon  the  infoimation 
available  at  that  time.  The  school  then  forv/ards  the  docu'-.ent  simul- 
taneously to: 

a.  DARCOM  commodity  command/development  center. 

b.  The  Logistics  Coniiand  Materiel  Directorate  for  reviev,'  and 
comment  on  reliability,  availability  and  maintainability  aspects,  if 
applicable,  and  Integrated  Logistics  Support  content  and  i equireisents . 

c.  TRADOC  proponent  and  integrating  centers  and  schools  for 
comment  and  information. 

A joint  working  group  may  then  be  formed  with  the  TRADOC  proponent  school 
providing  the  chairman  and  the  DARCOM  developing  commodity  corrimand  pro- 
viding the  vice-chai man . This  is  done  through  a formal  request  made 
directly  to  the  DARCOM  subordinate  element  by  the  TRADOC  proponent.  Ir;- 
formation  copies  go  to  TRADOC  (Deputy  Chief  of  Staff  Combat  Develcpmer, L) 
and  to  DARCOM  HQ. 

(1)  A transmitted  letter  establishes  a tentative  meeting 
date  for  the  joint  working  group  and  requests  comments  from  addressees 
no  later  than  30  days  from  the  date  of  the  letter. 
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(?)  rio  responses  from  addressees  arc  assumed  to  lie  con- 


currences (other  than  DARCOM). 

The  joint  working  groups  or  proponent  TRAHOC  school  will: 

a.  Refine  the  draft  frem  comments  received. 

b.  Prepare  the  document  in  proper  format. 

c.  Coo'dinate  tfie  draft  LOA  vn'th  elements  of  TRADOC  and  DARCC!" 
for  ^.oiniiient/ccncurrence.  Requests  for  comments  v/ill  be  made  within  30 
days  or  concurrence  is  assumed. 

(1)  Within  TRADOC: 

(a)  Other  interested  TRADOC  schools. 

(b)  The  proponent  integrating  center. 

(c)  Logistics  Center  for  reliability,  availability,  and 
maintainability  information,  if  applicable,  and  for  any  logistical  suppori; 
concept  inves Liya  Lions. 

(d)  Other  integrating  centers  that  nay  be  appropriate. 

(?)  Within  DARCOM: 

(a)  Test  and  Evaluation  Command  (TECOM).  TF.COM  will 
provide  their  comments  on  the  draft  LOA  to  tlie  Research  and  Development 
Directorate , DARCOM. 

(b)  Army  Materiel  Systems  Analysis  Agency  (AfISAA).  AM3AA 
provides  its  comments  on  tfie  draft  LOA  to  the  Plan.s  and  Analysis  Directocdte, 
DARCOM. 
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(c)  Lquipnient  Autfiorization  F^.eview  Acti vi ty  (EARA).  CARA 
provides  its  comments  on  the  draft  LOA  to  the  roqui  renients  and  Procureriiont 
Directorate,  DARCOM. 

d.  Provide  a rationale,  coordination  and  preliminary  appraisal 

index. 

e.  Insure  the  following  items  are  addressed  eit.her  in  the  main 
document  or  in  an  inclosure/annex: 

(1)  Nuclear  survivability 

(2)  COMSEC  (communications  security)  requirements. 

f.  Prepare  a letter  of  transmittal,  signed  jointly  by  the  joint 
worKing  group  chairman  and  vice-dici rman  and  submit  the  LOA  to  !1Q  DARCOM 
through  appropriate  channels.  Any  differences  which  may  still  be-  unresolved 
vjill  be  attacLicd  to  the  letter  of  transmittal. 

Tiie  integrating  TRADOC  proponent  center  will: 

a.  Insure  tlie  need  is  valid, 

b.  Resolve  those  differences  identified  du>^in(j  the  LOA  preparation 
reported  by  the  joint  working  group. 

c.  Insure  the  other  centers  and  major  subordinate  ccniiiiands  of 
DARCOM  receive  proper  coordination  whenever  required. 

d.  Insure  the  integrating  centers  receive  the  LOA  and  review 

and  provide  comments  pertaining  to  their  respective  areas  of  responsibility. 

e.  Forward  the  scliools  (or  joint  working  groups)  letter  of 
transi;ii  t'.tal  by  indorsement  and  provide  appropriate  recommendations . 
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The  proponent  DAP.COM  element.  Major  Subordinate  Command  (MSC), 
will  revicv.'  the  proposed  draft  LOA  received  from  the  school  or  joint 
worhing  group.  The  local  Foreign  Intelligence  Office  will  review  the 
threat  statements.  The  differences  identified  during  preparation  of 
the  draft  I OA  which  could  not  be  resolved  at  the  joint  working  group 
level,  will  be  resolved  between  DARCOil,  MSC  and  the  TPADCC  Integrating 
Center.  Cost  information  contained  in  the  document  which  is  provided 
by  DARCOM  elements  must  be  validated  by  the  MSC  Comptroller  or  Cost  Es- 
timating Control  Data  Cantor  prior  to  forwarding  the  document. 

The  action  officer  at  HO,  TRADOC,  Office  of  the  Deputy  Chief  of 
Staff  for  Combat  Development  (ODCSCD)  will  upon  receipt  of  the  draft  LOA: 

a.  Insure  coordination  of  the  draft  LOA  with  appropriate  staff- 
sections  of  ODCSCD  and  HQ  TRADOC  within  15  days  of  receipt.  Comments 
received  will  be  resolved  prior  to  further  staffing. 

b.  Forward  without  annexes,  to  HQ  DARCOM  requesting  comments 
concurrences  within  45  days.  Copies  will  be  forwarded  to  other  major 
commands,  services,  and  American,  British,  Canadian  and  Australian  (ABCA) 
countries  (if  releasable)  reouesting  their  comments  in  45  days  or  con- 
currences will  be  assumed.  An  -infornotion  copy  is  also  to  be  furnished 

HQDA  (da:;o-rqr). 

c.  Insure  appropriate  comments  are  incorporated  into  the  docu- 
ment. Any  comments  not  accepted  will  be  expUined  in  the  HQ  TRADOC 
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k. 
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coordination  annex.  (HQ's  Tl^ADOC  v/il1  withdraw  tfie  subordinate  ronniands 
coordination  annexes  and  will  keep  on  file). 

d.  Review  the  draft  LOA  to  insure  that  the  preliminary  appraisal 
is  in  agreement  with  the  latest  technical  and  cost  information  provided 

by  DARCOM. 

e.  Brief  the  TRADOC  Requirements  Review  Committee  (RRC).  Tlie 
RRC  will  insure  tfie  validity  of  the  need  and  the  pr'oposed  investigations 

to  develop  the  operational,  technical  and  logistical  support  concepts.  Trie 
preliminary  appraisal  i/iil  provide  the  basis  to  determine  that  the  pro- 
spective effectiveness  will  warrant  the  research  and  development  effort 
and  that  nuclear  survi vabil i ty  is  or  is  not  included.  The  RRC  will  recom- 
mend the  LO.A  be  forwarded  to  DCSCD  for  approval /signature  and  to  DARCO!! 
for  jo:nt  signature  or  tliat  it  be  returned  to  the  originator  with  specific 
reco/'.mendations  (i.e.,  revise,  terminate,  etc.). 

Disposition  of  the  proposed  LOA  after  approval/signaiure  by  the  DC.SCD 
is  to  BARCOii  for  joint  signature.  Upon  return  to  0DC3DC,  the  approved/ 
authenticated  LOA  is  forwarded  to  HQDA  (DAMO-RQR)  for  information  or 
approval  as  appropriate.  TPAL'TC  reproduces  and  distributes  the  approved 
LOA  to  all  interested  commands  and  activities. 
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and  the  fiatorie]  Acquisition  Handbook.  Infon.’iatiori  required  sficuid  be 
provided  consistent  witli  the  tnowlodge  available.  To  describe  tlie  system, 
the  following  LOA  format  is  required; 

a.  Need  for  the  systern. 

(1)  A brief  statement  of  why  the  system  is  requii'cd.  A dis- 
cussion of  the  capability  goal,  tfireat,  or  operational  deficiency  to  be 
achieved  or  overcome  should  be  presented. 

(2)  CARDS  reference  number:  (blank  until  approved  l)y  HQ 

TRADOC). 

b.  System  Concept.  A description  of  the  system,  its  early  ob- 
jectives or  characteri sties  stated  in  broad  hands  of  performance. 

c.  Prospective  relative  effectiveness.  A realistic  quantitative 
estimate  of  the  increase  in  effectiveness  believed  to  be  achievable  throuch 
the  potential  intrcduction  of  a new  or  improved  materiel  system.  This 
estimate  should  be  explained  in  the  context  of  the  "knowns  anri  unknovais" 
concerning  t!ie  proposed  new  system. 

d.  Prospective  upper  limit  on  unit  cost,  if  available.  An 
estimate  of  the  maximum  unit  cost  acceptable  to  achieve  the  desired  or 
a nti c i pa  ted  performance . 

e.  Investigations  needed  to  develop: 

(1)  Operational  emolo^'mont  concept.  A narrative  description 
of  the  activities  planned  by  the  co'bat  developer  to  develop  an  operational 
concept,  (i.e.,  field  tests,  experiments,  studies  and  analysis). 
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(2)  Technical  conceptii . A narrative  description  of  tfie 


r 

f 

I activities  planned  by  the  materiel  developer  to  develop  a technical  con- 

cept (i.e.,  an  engineering  analysis,  investigations  and  developmental 
tests) . 

(3)  Logistical  support  concept.  A narrative  description  of 
the  activities  needed  to  identify  potential  logistical  requi>'cments , pre- 
liminary qualitative  and  quantitative  personnel  requirements  and  alternate 
support  concepts,  (i.e.,  analysis  of  equipment  and  maintenance  data  on 
fielded  systems  migfit  be  a source). 

f.  Unknoivns  to  be  resolved.  A listing  and  brief  summary  dis- 
cussion of  potential  knov/n  unknov/ns  or  uncertainty  that  may  require  reso- 
lution through  the  activities  listed  in  paragraph  e. 

g.  Technical  risk.  A listing  and  assessment  of  the  technical 
risks  involved  to  include  state-of-the-art  technology  that  has,  as  yet, 
not  been  successfully  demonstrated. 

I 

h.  Schedules  and  milestones.  A listing  of  the  schedules  and 

I 

milestones  for  accomplishment  of  tlie  actions  described  in  the  l.OA.  The 
primary  emphasis  should  be  on  event  completion  and  not  time  orientation. 
Milestones,  !iov/ever,  should  be  phased  to  provide  synchronous  interaction 
by  all  participants  to  eliminate  time  gaps  prior  to  entry  into  full-scale 
development. 

i.  Critical  issues  for  tests.  A listing  and  brief  disciissiion 
of  critical  issues  and  tests  required  to  resolve  the  issue. 
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j.  Advanced  development  funds.  A cost  assessment  section 
usually  inserted  as  an  appendix  to  the  I.OA  contains  an  estimate  of  the 
Advanced  Developiiiont  (6.3)  costs.  If  practicable,  ftigineering  Develop- 
ment (6.4)  costs  arc  also  supplied.  A standard  format  may  be  found  in 
Appendix  A,  page  10-A-l  of  the  Materiel  Acquisition  Handbook.  The  esti- 
mate includes  a range  estimate  for  Advanced  Development  funds  in  inflated 
base  year  dollars  along  with  a fiscal  year  display.  The  sum  of  the  funds 
by  fiscal  year  should  total  a number  that  falls  within  the  upper  and 
lower  bounds  of  the  range  and  will  be  considered  the  expected  cost.  A 
display  by  fiscal  year  showing  constant  year  dollars  should  be  shown  below 
the  inflated  year  dollars  in  the  display. 

A broad  base  Dngineering  Development  estimate  is  also  required. 

This  estimate  is  also  displayed  by  fiscal  year  and  its  sum  of  all  year 
dollars  mnsl  also  fall  witliiii  the  estimated  dollar  range. 

The  AD  a DO  sections  should  list  the  cpiantity  ef  prototypes  to  bo 
fabricated  in  the  research  and  development  phase. 

The  final  section  of  the  LOA  cost  assessnient  should  contain  a broad 
based  estimate  of  the  unit  flyaway  cost  expressed  in  constant  year  dollars 
v/hich  can  do  used  to  forimulate  a prospective  upper  limit  unit  cost,  if 
a va  i 1 a b ! e . 

The  r.i'teriel  developer  will  prepare  broaa  base  esti, mates  oi  unit 
flya.wjy  costs  to  be  used  to  fori’.ulate  tin;  prospective  upper  limit  on 
unit.  cost.  (0.  10-1) 
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slxtio:j  V 


CVALUATIOII  OF  CURRFIIT  LOA  PROCFDL'RES 

An  attempt  to  gain  sor.ie  insight  into  the  effectiveness  of  current 
procedures  concerning  the  generation  and  processing  of  LOA's  was  con- 
ducted. Interviews  with  Action  Officers  from  four  different  headquarters 
were  conducted  to  gain  a feel  for  tlieir  perceptions  of  the  current  systei.i 
and  the  difficulties  encountered  as  an  LOA  takes  form.  (12)  An  attempt 
was  made  to  gain  some  balance  in  the  views  expressed  l)y  talking  to  both 
con, bat  developers  and  materiel  developers. 

Potential  Con fl_i £t 

Although  several  areas  of  potential  conflict  surfaced  as  a cause 
for  disagreement  between  the  user  and  developer  in  generating  the  LOA, 
it  i/as  possible  to  confine  them  to  basically  differences  in  the  philosophi 
behind  tlieir  approach  to  the  problem.  Philosophical  differences  in  per- 
ceiving the  need  for  early  on  specificity  of  requi reinents , the  approaches 
to  reporting  tlie  potential  development  and  unit  costs  and  the  require- 
ments for  early  hands-on  testing  of  equipment  are  tlie  principle  complaints 

It  should  bo  noted  at  this  point,  ho'/ever,  that  those  areas  of  con- 
cern '„crc  not  considered  unresolvahle  by  eitlier  the  user  or  developer. 

As  a natter  of  fact,  both  wc^e  extremely  pleased  \;i  i.h  the  establislied  sys- 
tem of  generating  the  I.CA  and  expressed  these  areas  as  being  only  areas 
of  potential  conflict  when  pressed  to  give  specifics.  (More  will  he  said 
about  the  total  process  tov.ard  the  end  i.if  this  section.) 


i In  the  cirea  of  perceiving  the  need  for  specificity  of  requirements , 


it  is  the  user's  vie:/  that  this  is  necessary  for  a couple  of  reasons. 

First,  they  are  aware  of  the  specific  needs  the  system  will  be  required 
to  fulfill  in  much  better  terms  than  the  developer.  Second,  they  per- 
ceive the  need  to  meet  specific  requirements  as  a better  method  of  tieing 
down  cost  factors  early  in  the  game  as  long  as  technology  to  meet  the 
need  is  available.  They  are  prepared  to  back  off  in  this  area  when  the 
state-of-the-art  has  not  been  adequately  demonstrated. 

The  developer,  on  the  other  hand,  perceives  specificity  at  the  LOA 
stage  as  being  a restriction  of  his  flexibility  to  be  creative  and  innova- 
tive to  meet  the  need  requirement.  They  i;ould  much  rather  have  the  re- 
quirements stated  in  broad  and  general  terms.  The  belief  is  that  restrict- 
ing the  needs  to  tie  down  costs  at  this  stage  of  development  is  much  too 
soon  based  up'on  the  risk  and  uncertainties  of  developmental  roqu  ireiiieivts , 
They  perceive  the  keeping  of  costs  at  low  levels  to  be  an  attempt  by  tiie 

user  at  making  the  system  as  desirable  as  possible  from  a cost  standpoint 

in  order  to  get  eventual  approval  for  tlie  system  to  proceed  into  develop- 
ment. Admittedly,  this  is  of  interest  to  the  developer  also. 

The  approaches  to  reporting  development  and  unit  cost  is  a result 
of  and  a contintmiion  of  the  previous  lopic.  There  is  a basic  dichotomy 

involved  in  both  the  side  of  the  user  and  developer  on  the  issue  of  cost. 

F.ach  knc'.,'s  that  affordability  of  a system  is  a major  issue  in  whether  jt 
can  proceed  to  development  and  eventual  fielding.  To  be  approved. 
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therefore,  costs  r.nist  be  reasonable  and  preferably  on  the  "lov/"  side, 
both  agree.  To  avoid  charges  of  being  unrealistic  and  eventual  broaching 
of  the  LOA  thresholds  due  to  areas  of  high  risk  or  uncertainty,  there  is 
great  reluctance  on  the  part  of  the  developer  to  he  anything  but  conserva- 
tive in  the  cost  estimate.  Since  the  developer  prepares  the  cost  estimate, 
he  is  better  aware  of  teclinological  risk  and  uncertainty,  and  realizes  the 
consequences  of  breaching  cost  thresholds  due  to  overruns  and  the  eventual 
impending  criticism  of  the  user,  service  staff,  OSD,  and  Congress;  he  is 
in  a real  dilemma.  The  user  and  developer  must  necessarily  then  give 
the  cost  estimate  of  development  and  potential  unit  cost  their  best  shot 
and  be  prepared  to  back  it  up  under  all  scrutiny.  There  must  be  a rapport 
established  early  on,  of  mutual  trust  and  agreement  that  both  user  and 
dovclofer  are  sincere  and  dedicated  to  attain  the  development  of  a system 
that  \/ill  servo  the  soldier  and,  at  the  same  time,  protect  the  interests 
of  the  taxpayer. 

The  requirei.’.ent  for  early  hands-on  testing  of  equipment  tends  to 
bother  the  developer  to  some  extent.  The  view  is  that  early  developmental 
items  are  not  suitable  for  user  tests  and  are  primarily  only  to  test  feasi- 
bility. The  equipment  is  not  hardened,  is  still  very  much  ill -defined  as 
to  being  nper ational ly  suitable  and  tends  to  he  of  a coirrigura tion  which 
will  change  drastically  before  full  scale  production.  Jt  is  feit  tiiat 
hands-on  testing  at  this  point  will  he  detrimental  to  user  acceptance 
of  a later  improved  version. 


')C 


u u 


The  user  on  the  other  liand  arfjues  this  is  not  the  case.  Tney  know 
and  realize  the  limitations  of  prototypes  and  models  at  tin's  stage  of 
development.  However,  they  are  extremely  interested  in  breadboard  and 
brassboard  models  in  order  to  evaluate  the  equipment  specifically  for 
imperfections  which  are  not  well-documented  and  known,  and  which  may  not 
be  designated  for  change  in  later  development.  To  tliis  is  added  the 
opportunity  also  to  evaluate  some  of  the  operational,  doctrinal,  and 
training  concepts  which  have  been  hypothesized. 

Once  these  areas  of  potential  conflict  are  resolved  at  the  working 
levels,  be  it  tiie  TRADOC  schools  and  DARCCM  commodity  comiiiands  or  the 
joint  working  group,  the  next  major  hurdles  are  staffing  through  the  major 
headquarters  and  comnionds.  One  of  the  major  problems  in  completing  tiie 
staffing  evolves  due  to  erroneous  or  overly  optimistic  representations 
v.’hich  are  made  at  various  levels  within  the  headquarters  and  commands. 

As  an  LOA  is  being  generated,  interest  in  potential  systems  and  approaches 
to  solving  the  need  requirement  are  also  being  generated.  Within  a very 
short  period  of  time  various  contractors  begin  briefing  their  solutions 
up  the  tape  and  soon  various  configurations,  approaches,  and  cost  esti- 
mates and  figures  that  have  been  throv/n  out  begin  sticking  in  the  minds 
of  personnel  attending  the  briefings. 

When  inappropriately  apoliod,  this  type  of  information  can  cause 
the  piocessing  of  tiie  LOA  to  bo  delayed  until  vai-ious  studies,  and  infor- 
mational briefings  prepared  by  both  the  user  and  dc-velopor  can  put  to 
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bed  the  issues  which  have  been  ycneratod  by  overly  eager  and  optimistic 
contractor  personnel  who  have  been  trying  to  sell  interest  in  their  pro- 
ducts. Often  these  activities  have  resulted  in  the  user  and  developer 
being  directed  back  to  ground  zero  until  issues  could  be  resolved. 

What's  Right  About  the  Procodures? 

So  far  the  discussions  in  this  section  liave  dealt  with  potential 
conflict  areas.  The  overv.'helming  comments  from  both  user  and  developer 
concerning  the  LOA  procedures,  however,  have  not  been  related  to  conflict 
but  to  the  resolution  of  conflict.  The  primary  statements  have  bsen 
favorable  and  enthusiastic  in  their  praise  of  tlie  procedure. 

The  thread  'vhicii  seemed  to  run  tir'ough  the  comrnonts  of  hoth  the 
user  and  developer  pertain  to  the  fact  that  the  LOA  is  now  a user  and 
developer  joint  requirement.  A major  step  has  been  getting  the  two  to- 
gether and  in  so  doing,  hammering  out  an  agreement  acceptable  to  both 
through  which  each  has  as  its  goal  the  overall  interests  of  the  Army  as  a 
prime  motivator.  It  has  been  the  catalyst  whereby  each  can  appreciate 
the  problems  and  perceptions  of  the  other  as  the  development  of  a system 
begins  to  lake  shape.  As  a result,  the  user  is  no  longer  asking  for  un- 
deliverables and  the  developer  is  no  longer  promising  them. 
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SECTION  VI 
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Conclusions 

Eroi’i  tho  precooding  discussion  there  is  evidence  that  the  materiel 
acquisition  process  within  the  Army  has  been  modified  to  take  into  account 
its  critics  comments.  Indications  are  that  the  Army's  attempt  to  define 
the  need  requirements  through  the  use  of  the  LOA  has  been  quite  success- 
ful. That  is  if  one  looks  only  at  tho  degree  of  satisfaction  \;hich  the 
personnel  who  operate  the  system  of  defining  the  requirements  are  con- 
cerned. So  far  the  Army  has  led  tiie  way  with  this  rather  unique  and  in- 
novative method  of  defining  needs  prior  to  entering  the  conceptual  and 
validation  phase  with  a locked-in  requirement.  The  use  of  the  LOA  to 
enter  the  conceptual  and  validation  phases  and  then  the  ROC,  which  firms 
up  the  needs  prior  to  entering  full-scale  development  appears  to  be  highly 
successful.  It  is  so  logical,  in  fact,  that  it  has  previously  been 
hiding  "the  forest  because  of  all  the  trees". 

Recommendations. 

Although  it  may  be  concluded  that  the  use  of  tho  LOA  has  been  success- 
fully implemented,  the  question  which  might  logically  be  asked  is,  "what 
impart  has  the  adoptiori  of  tiie  LOA  had  on  speeding  up  the  overall  materiel 
acquisition  process,  and  what  has  Leon  tfie  improvement  in  the  savings  of 
time,  money  and  effort  to  meet  perfurirance  requirements?"  Unfortunately, 
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it  is  not  within  the  scope  of  the  paper  to  explore  and  make  an  evaluation 
of  that  type  of  question.  It  may  well  be  yet  too  early  to  assess  the 
impact  of  that  question  since  the  process  itself  is  still  relatively  new. 

A study  of  tliis  type  is  recommended  as  a follow-on  to  this  parti- 
cular study  effort  as  a future  project.  To  find  out  just  how  well  the 
Army  is  doing  since  it  atopted  the  LOA  could  [lave  considerable  impact 
on  soiv,e  of  t!ie  Army's  critics,  especially  if  the  results  of  the  study 
were  found  to  be  favorable. 

J J cai^ions. 

As  can  be  seen,  the  process  of  getting  an  LOA  through  to  ultimate 
approval  to  enter  the  conceptual  and  validation  phase  is  just  the  beginning, 
harapii -.sing  that  famous  Ainerican  cartoon  character  Peanuts,  "Happiness  for 
a pr'r'sperti ve  PM,  an  approved  LOA"  is  just  the  start  of  the  battle  to 
begin  development.  The  LOA  is  no  finn  commitment  to  begin  the  process  of 
development.  Approval  of  the  LOA  signals  the  beginning  of  the  very  real 
problem  of  getting  the  funds  released  to  proceed.  It  is  only  then  that 
the  PM  can  "do  his  thing".  However,  with  joint  agreement  between  user 
and  developer,  a concerted  effort  will  normally  be  rewarded  favorably. 

The  successful  iriplementaticii  of  the  need  requirements  generation 
prcblc!;'  fdirough  tiie  use  the  LOA  should  iijoact  favorably  on  the  critics 
of  the  Ansy's  acquisition  procedures.  This,  in  itself,  will  be  a major 
Step  forward  and  should  allow  itore  effort  to  he  applied  to  tlie  diallenge 
of  getting  now  and  improved  systems  into  t'ne  hands  of  the  ultimate  users. 
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